General: Forums subtopic: App & System Services > Networking DevForums tag: Network Extension Network Extension framework documentation Routing your VPN network traffic article Filtering traffic by URL sample code Filtering Network Traffic sample code TN3120 Expected use cases for Network Extension packet tunnel providers technote TN3134 Network Extension provider deployment technote TN3165 Packet Filter is not API technote Network Extension and VPN Glossary forums post Debugging a Network Extension Provider forums post Exporting a Developer ID Network Extension forums post Network Extension Framework Entitlements forums post Network Extension vs ad hoc techniques on macOS forums post Network Extension Provider Packaging forums post NWEndpoint History and Advice forums post Extra-ordinary Networking forums post Wi-Fi management: Understanding NEHotspotConfigurationErrorInternal forums post See also Networking Resources for general networking resources, including information about Wi-Fi. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

I'm building a gambling addiction recovery app for macOS that uses NEFilterDataProvider to block 208,000+ gambling domains system-wide. The app is already live on the iOS App Store under the same developer account. I need the restricted entitlement com.apple.developer.network-extension.content-filter to distribute via the Mac App Store. I submitted a request through Developer Support > Development and Technical Information > Rights/Entitlements (case #102914968660) on June 14th — 9 days ago with no response yet. My questions: Is this the correct channel for requesting this entitlement for Mac App Store distribution? Has anyone successfully obtained this entitlement? What channel/process worked for you? Is there a typical turnaround time I should expect? Any guidance appreciated. Thanks

Howdy, I've noticed a strange behavior recently on my macos (26.5.1) when using my System Extension-hosted Network Extension with a Packet Tunnel Provider inside: let dnsSettings = NEDNSOverHTTPSSettings(servers: ["8.8.8.8", "8.8.4.4"]) dnsSettings.serverURL = URL(string: "https://dns.google/dns-query") settings.dnsSettings = dnsSettings I have always expected this block to not need any DNS resolution, since IPs for dns.google are preconfigured, however not sure it's been the case lately. I see normal DNS requests to the addresses above to :53. Once resolved, no more DNS traffic, just :443 via TUN. Is it possible that some changes were introduced in the past months that would make macos to have to resolve dns.google with regular DNS before switching over to DoH?

macOS allows you to directly distribute a Network Extension using Developer ID signing, but with an important wrinkle. This post explains that wrinkle, its affect on Xcode, and how you get around it. If you have questions or comments, start a new thread here on the forums. Put it in the App & System Services > Networking and tag it with Network Extension. That way I’ll be sure to see it go by. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Exporting a Developer ID Network Extension macOS supports a variety of Network Extension (NE) provider types. Starting with macOS 10.15, it’s possible to distribute an app containing NE providers directly, using Developer ID signing. See TN3134 Network Extension provider deployment for the full list of supported provider types. For your NE provider to work when distributed directly, it must: Be packaged as a system extension. Use Developer ID specific entitlements This post is focused on that second point, because it’s a common source of confusion. Note If you’re currently shipping an app extension and you want to move to a system extension, see Network Extension Provider Packaging. This post assumes that you’re building your app with Xcode; if you’re building your app outside of Xcode, you’ll have to adapt these steps to your build system. Entitlement Matters A Network Extension system extension and its container app must be signed with the Network Extension entitlement (com.apple.developer.networking.networkextension). That entitlement is an array, with a variety of different element values based on the provider type. For example, a standard NE content filter provider must include the content-filter-provider value. There are two groups of these values: the standard ones and the ones with the -systemextension suffix. During development and for App Store distribution, use the appropriate standard value. For direct distribution using Developer ID, use the corresponding value with the -systemextension suffix. For example, a Developer ID signed NE content filter must use content-filter-provider-systemextension instead of content-filter-provider. Xcode Issues IMPORTANT Xcode 27.0b1 is reported to have fixed this issue, meaning that it should now be possible to export a Developer ID signed app with an Network Extension system extension from the Xcode organiser. I did some basic tests of that here in my office and it seems to work. Yay! So the following is only relevant if you have to build your app with an earlier version of Xcode. Xcode 26 and earlier are not aware of this requirement. If you build your NE provider container app using Xcode, you might expect to export it for direct distribution using the Direct Distribution workflow in the Xcode organiser. This does not work on older versions of Xcode (r. 108838909). To get around this, manually export your app from your Xcode archive. Before attempting that, there are a few things to confirm: By default Xcode’s Signing & Capabilities editor uses the standard values for the NE entitlement. Leave them that way. During day-to-day development it’s best to use an Apple Development signing identity [1], and the standard values work with that. Continue to use Build > Archive [2] to create an Xcode archive for your product. The steps below replace the Direct Distribution workflow, and they assume you’re starting with an Xcode archive. Note For hints and tips about how to bring up and then debug an NE provider, see Debugging a Network Extension Provider. [1] Don’t use Developer ID for day-to-day development; see The Care and Feeding of Developer ID for more on that topic. [2] Or, if you’re automating this, the archive action in xcodebuild. Assemble Your Assets Imagine you’re working on a content filter for the Mac called WaffleFilter. You’ve used Xcode to build the app into an Xcode archive: % ls "WaffleFilter.xcarchive/Products/Applications" WaffleFilter.app That app is development signed: % codesign -d -vvv "WaffleFilter.xcarchive/Products/Applications/WaffleFilter.app" … Authority=Apple Development: … … IMPORTANT The steps in this section are based on the much more comprehensive instructions in Creating distribution-signed code for macOS. If anything is unclear, read that documentation for clarification. To re-sign this app for direct distribution you’ll need three things: A Developer ID application signing identity. This is named Developer ID Application: TTT, where TTT identifies your team. A Developer ID provisioning profile for the app. In this example I’ve called this WaffleFilter_Dev_ID.provisionprofile. A Developer ID provisioning profile for the system extension. In this example I’ve named this WaffleFilter_WFProvider_DevID.provisionprofile. If you’re not sure how to create these things, see Developer Account Help. Re-sign the App To start, make a copy of the app: % ditto "WaffleFilter.xcarchive/Products/Applications/WaffleFilter.app" "WaffleFilter.app" Dump the entitlements of the app and its embedded system extension: % codesign -d --entitlements "WaffleFilter.entitlements" --xml "WaffleFilter.app" % codesign -d --entitlements "WaffleFilter_WFProvider.entitlements" --xml "WaffleFilter.app/Contents/Library/SystemExtensions/com.example.apple-samplecode.WaffleFilter.WFProvider.systemextension" And reformat them to make them more readable: % plutil -convert xml1 "WaffleFilter.entitlements" % plutil -convert xml1 "WaffleFilter_WFProvider.entitlements" Now edit these files to add the -systemextension suffix. The result will look something like this: % cat "WaffleFilter.entitlements" … <dict> … <key>com.apple.developer.networking.networkextension</key> <array> <string>content-filter-provider-systemextension</string> </array> … </dict> </plist> % cat "WaffleFilter_WFProvider.entitlements" … <dict> … <key>com.apple.developer.networking.networkextension</key> <array> <string>content-filter-provider-systemextension</string> </array> … </dict> </plist> Before you re-sign with these entitlements, replace the embedded provisioning profiles with their Developer ID variants: % cp "WaffleFilter_Dev_ID.provisionprofile" "WaffleFilter.app/Contents/embedded.provisionprofile" % cp "WaffleFilter_WFProvider_DevID.provisionprofile" "WaffleFilter.app/Contents/Library/SystemExtensions/com.example.apple-samplecode.WaffleFilter.WFProvider.systemextension/Contents/embedded.provisionprofile" Now re-sign the app and the system extension with their new entitlements, from the inside out: % codesign -s "Developer ID Application" -f --entitlements "WaffleFilter_WFProvider.entitlements" --timestamp -o runtime "WaffleFilter.app/Contents/Library/SystemExtensions/com.example.apple-samplecode.WaffleFilter.WFProvider.systemextension" WaffleFilter.app/Contents/Library/SystemExtensions/com.example.apple-samplecode.WaffleFilter.WFProvider.systemextension: replacing existing signature % codesign -s "Developer ID Application" -f --entitlements "WaffleFilter.entitlements" --timestamp -o runtime "WaffleFilter.app" WaffleFilter.app: replacing existing signature If you have multiple Developer ID Application signing identities, you’ll need to replace Developer ID Application with the name of the specific identity you want to use. IMPORTANT If your app contains other code items, like frameworks or an app extension, re-sign those as well. For advice on how to manually re-sign a more complex app, see Creating distribution-signed code for macOS. And you’re done! Manually Notarise Xcode’s Direct Distribution workflow also deals with notarisation. As you’re not using that workflow, manually notarise your app. For advice on how to do that, see Customizing the notarization workflow. You should also look at Packaging Mac Software for Distribution, which has a bunch of general info about packaging Mac apps. Revision History 2026-06-22 Xcode 27.0b1 is reported to have fixed this issue. Added information about that. Made other minor editorial changes. 2023-09-21 First posted.

I am testing NEURLFilter on macOS using the SimpleURLFilter sample, and I am seeing a failure from neagent while it is saving the local URL prefilter Bloom filter to its mmap file. The relevant log is: neagent +[NEBloomFilter mmapToFile:data:dataLength:numberOfBits:numberOfHashes:murmurSeed:tag:]: NEBloomFilter - failed to open mmap file /private/var/db/urlPrefilter/com.apple.networkextension.url-prefilter-data.temp.com.example.apple-samplecode.SimpleURLFilterTC3Q7MAJXF <errno 13 - Permission denied> neagent <NEAgentURLFilterExtension: 0xc8ce64280>: -[NEAgentURLFilterExtension startURLFilter]_block_invoke - Failed to save first fetch of pre-filter data Environment: macOS: 26.5.1 (25F80) Xcode: 26.5 (17F42) Platform: macOS Signing type: Apple Development (automatically manage signing) What I am doing: Build and run the containing app. Save and enable the NEURLFilterManager configuration. The URL filter provider starts. The provider's prefilter code is reached. neagent logs the mmap failure above while trying to open a temporary file under /private/var/db/urlPrefilter. Expected result: neagent should be able to create or open its system-managed URL prefilter cache / mmap file under /private/var/db/urlPrefilter, and the local Bloom filter should be loaded successfully. Actual result: neagent fails to open the temporary mmap file with errno 13 Permission denied: /private/var/db/urlPrefilter/com.apple.networkextension.url-prefilter-data.temp.<bundle/team-specific suffix> I am not manually creating, modifying, or chmod/chown-ing /private/var/db/urlPrefilter or anything inside it. The directory and its contents are entirely system-managed. The failure appears to happen inside neagent while it is handling the system-managed URL prefilter cache. The failure occurs at the mmapToFile: step while neagent saves the Bloom filter prefilter data. Directory state: drwxr-xr-x 2 root wheel 64 /private/var/db/urlPrefilter Has anyone else encountered this? Any suggestions on what could cause neagent to fail with errno 13 on its own mmap file under /private/var/db/urlPrefilter?

One thing I wanted to confirm, suppose i submit one request to onboard OHTTP relay for one organisation app and it gets approved, so can I re submit the request with different bundle ID for other organisation and same PIR server, same OHTTP server ? Or do we need different domain name ?

I haven’t been able to get this to work at any level! I’m running into multiple issues, any light shed on any of these would be nice: I can’t implement a bloom filter that produces the same output as can be found in the SimpleURLFilter sample project, after following the textual description of it that’s available in the documentation. No clue what my implementation is doing wrong, and because of the nature of hashing, there is no way to know. Specifically: The web is full of implementations of FNV-1a and MurmurHash3, and they all produce different hashes for the same input. Can we get the proper hashes for some sample strings, so we know which is the “correct” one? Similarly, different implementations use different encodings for the strings to hash. Which should we use here? The formulas for numberOfBits and numberOfHashes give Doubles and assign them to Ints. It seems we should do this conversing by rounding them, is this correct? Can we get a sample correct value for the combined hash, so we can verify our implementations against it? Or ignoring all of the above, can we have the actual code instead of a textual description of it? 😓 I managed to get Settings to register my first attempt at this extension in beta 1. Now, in beta 2, any other project (including the sample code) will redirect to Settings, show the Allow/Deny message box, I tap Allow, and then nothing happens. This must be a bug, right? Whenever I try to enable the only extension that Settings accepted (by setting its isEnabled to true), its status goes to .stopped and the error is, of course, .unknown. How do I debug this? While the extension is .stopped, ALL URL LOADS are blocked on the device. Is this to be expected? (shouldFailClosed is set to false) Is there any way to manually reload the bloom filter? My app ships blocklist updates with background push, so it would be wasteful to fetch the filter at a fixed interval. If so, can we opt out of the periodic fetch altogether? I initially believed the API to be near useless because I didn’t know of its “fuzzy matching” capabilities, which I’ve discovered by accident in a forum post. It’d be nice if those were documented somewhere! Thanks!!

Eons ago we were approved in the older entitlement method where we had to apply an Entitlement to our provisioning profile via a dropdown. We'd basically attach "Local Push Provider (Dist)" to our profile. That broke in May of 2025 when our fastlane process could no longer automate the creation of a provisioning profile with that profile attached. We learned the future was the capabilities so we submitted a request to migrate our Local Push Provider to a capability - https://developer.apple.com/contact/request/entitlement-migration-requests/ Meanwhile a new client wanted a white-labeled iteration of our app. So a new client requested the capability of Local Push via https://developer.apple.com/contact/request/local-push-connectivity and it worked in roughly 4 weeks. Their account now has "Network Extensions (additional values)" on the identifier which grants access to app-push-provider. Our build is fully automated - everything works. So we waited on our migration request and after months passed, we submitted in October of 2025 a new entitlement request for Local Push as our submit to migrate went stale. It never arrived again. So I started a case in 2026 roughly 6 months later - 102869206062. After many escalations I've been told: I wanted to provide an update to you regarding your entitlement request. It appears that your entitlement no longer requires a request. The channel you’ve reached is actually set up to provide administrative support to Apple Developers and those enrolled in the Apple Developer Program I just wanted to follow-up with you and ask you to please request the Network Extensions Entitlement again (19627183) It seems the overarching point is Network Extensions are no longer required for approval, but it seems app-push-provider (LocalPush) is. I don't want a random forum post to be a support thread. So looking for clarity on 2 points. Can you obtain app-push-provider (network extension) without Apple approval? Is this doc out of date? https://developer.apple.com/documentation/networkextension/local-push-connectivity To use the Local Push Connectivity API, your app must have the Network Extensions Entitlement with the app-push-provider value. Request this entitlement from the Entitlement Request Page. After you receive the entitlement, apply it to both your app target and your provider extension target. tldr; ➜ Desktop security cms -D -i match_ClientApp.mobileprovision| plutil -p - | grep 'push' 0 => "app-push-provider" ➜ Desktop security cms -D -i match_OurApp.mobileprovision| plutil -p - | grep 'push' ➜ Desktop

Hello, We have a security solution which intercepts network traffic for inspection using a combination of Transparent Proxy Provider and Content filter. Lately we are seeing reports from the market that on M5 Macbooks and A18 Neos the system will kernel panic using our solution, even though it never happens on M1-M4 and no significant code changes were made in the mean time. All crashes seem to be related to an internal double free in the kernel: panic(cpu 0 caller 0xfffffe003bb68224): skmem_slab_free_locked: attempt to free invalid or already-freed obj 0xf2fffe29e15f2400 on skm 0xf6fffe2518aaa200 @skmem_slab.c:646 Debugger message: panic Memory ID: 0xff OS release type: User OS version: 25D2128 Kernel version: Darwin Kernel Version 25.3.0: Wed Jan 28 20:54:38 PST 2026; root:xnu-12377.91.3~2/RELEASE_ARM64_T6050 Additionally, from further log inspection, before panics we find some weird kernel messages which seem to be related to some DMA operations gone wrong in the network driver on some machines: 2026-03-30 14:11:21.779124+0300 0x30f2 Default 0x0 873 0 Arc: (Network) [com.apple.network:connection] [C9.1.1.1 IPv4#e5b4bb04:443 in_progress socket-flow (satisfied (Path is satisfied), interface: en0[802.11], ipv4, ipv6, dns, uses wifi, flow divert agg: 1, LQM: good)] event: flow:start_connect @0.075s 2026-03-30 14:11:21.780015+0300 0x1894 Default 0x0 0 0 kernel: (402262746): No more valid control units, disabling flow divert 2026-03-30 14:11:21.780017+0300 0x1894 Default 0x0 0 0 kernel: (402262746): Skipped all flow divert services, disabling flow divert 2026-03-30 14:11:21.780102+0300 0x1894 Default 0x0 0 0 kernel: SK[2]: flow_entry_alloc fe "0 proc kernel_task(0)Arc nx_port 1 flow_uuid D46E230E-B826-4E0A-8C59-4C4C8BF6AA60 flags 0x14120<CONNECTED,QOS_MARKING,EXT_PORT,EXT_FLOWID> ipver=4,src=<IPv4-redacted>.49703,dst=<IPv4-redacted>.443,proto=0x06 mask=0x0000003f,hash=0x04e0a750 tp_proto=0x06" 2026-03-30 14:11:21.780194+0300 0x1894 Default 0x0 0 0 kernel: tcp connect outgoing: [<IPv4-redacted>:49703<-><IPv4-redacted>:443] interface: en0 (skipped: 0) so_gencnt: 14634 t_state: SYN_SENT process: Arc:873 SYN in/out: 0/1 bytes in/out: 0/0 pkts in/out: 0/0 rtt: 0.0 ms rttvar: 250.0 ms base_rtt: 0 ms error: 0 so_error: 0 svc/tc: 0 flow: 0x9878386f 2026-03-30 14:11:21.934431+0300 0xed Default 0x0 0 0 kernel: Hit error condition (not panicking as we're in error handler): t8110dart <private> (dart-apcie0): invalid SID 2 TTBR access: level 1 table_index 0 page_offset 0x2 2026-03-30 14:11:21.934432+0300 0xed Default 0x0 0 0 kernel: [ 73.511690]: arm_cpu_init(): cpu 6 online 2026-03-30 14:11:21.934441+0300 0xed Default 0x0 0 0 kernel: [ 73.511696]: arm_cpu_init(): cpu 9 online 2026-03-30 14:11:21.934441+0300 0xed Default 0x0 0 0 kernel: [ 73.569033]: arm_cpu_init(): cpu 6 online 2026-03-30 14:11:21.934441+0300 0xed Default 0x0 0 0 kernel: [ 73.569038]: arm_cpu_init(): cpu 9 online 2026-03-30 14:11:21.934442+0300 0xed Default 0x0 0 0 kernel: [ 73.577453]: arm_cpu_init(): cpu 7 online 2026-03-30 14:11:21.934442+0300 0xed Default 0x0 0 0 kernel: [ 73.586328]: arm_cpu_init(): cpu 5 online 2026-03-30 14:11:21.934442+0300 0xed Default 0x0 0 0 kernel: [ 73.586332]: arm_cpu_init(): cpu 8 online 2026-03-30 14:11:21.934442+0300 0xed Default 0x0 0 0 kernel: [ 73.621392]: (dart-apcie0) AppleT8110DART::_fatalException: dart-apcie0 (<ptr>): DART DART SID exception ERROR_SID_SUMMARY 0x00003000 ERROR_ADDRESS 0x0000000000009800 2026-03-30 14:11:21.934443+0300 0xed Default 0x0 0 0 kernel: [ 73.621397]: Hit error condition (not panicking as we're in error handler): 2026-03-30 14:11:21.934443+0300 0xed Default 0x0 0 0 kernel: t8110dart <ptr> (dart-apcie0): invalid SID 2 TTBR access: level 1 table_index 0 page_offset 0x2Expect a `deadbeef` in the error messages below 2026-03-30 14:11:21.934452+0300 0xed Default 0x0 0 0 kernel: Expect a `deadbeef` in the error messages below 2026-03-30 14:11:21.934456+0300 0xed Default 0x0 0 0 kernel: (AppleEmbeddedPCIE) apcie[0:centauri-control]::_dartErrorHandler() InvalidPTE caused by read from address 0x9800 by SID 2 (RID 2:0:1/useCount 1/device <private>) 2026-03-30 14:11:21.934469+0300 0xed Default 0x0 0 0 kernel: (AppleT8110DART) Ignored dart-apcie0 (0xfbfffe18820b0000): DART(DART) error: SID 2 PTE invalid exception on read of DVA 0x9800 (SEG 0 PTE 0x2) ERROR_SID_SUMMARY 0x00003000 TIME 0x11242d43fd TTE 0xffffffffffffffff AXI_ID 0 We do not have any correlation between machines, usage pattern or installed applications. Uninstalling the network protection features seem to largely fix the issues, even though we have heard of crashes happening even in safe mode or with our network extension disabled from system settings. We weren't able to reproduce internally and it seems to happen completely random on client machines, but often enough to be disrupting. Can you tell us please if this is a known problem and if there's a workaround or what can we do to narrow it down? Thanks.

I've seen a number of similar posts from other network system extension developers reporting kernel panics on M5 devices in macOS. These kernel panics occur when network system extensions are enabled and are not observed on earlier mac platforms or versions of macOS. Reference: https://developer.apple.com/forums/thread/821372 In this post, it appears like Apple is aware of a problem as noted by Kevin Elliott in versions of macOS. Do we know if there is any way to work around this problem (short of not enabling a network filter) until a fix is available?

I’m encountering a persistent issue with my Network Extension (specifically NEFilterDataProvider) and would really appreciate any insights. The extension generally works as expected, but after some time — especially after sleep/wake cycles or network changes — a global network outage occurs. During this state, no network traffic works: pings fail, browsers can’t load pages, etc. As soon as I stop the extension (by disabling it in System Preferences), the network immediately recovers. If I re-enable it, the outage returns instantly. I’ve also noticed that once this happens, the extension stops receiving callbacks like handleNewFlow(), and reinstalling the app or restarting the extension doesn’t help. The only thing that resolves the issue is rebooting the system. After reboot, the extension works fine again — until the problem reoccurs later. I asked AI about this behavior, and it suggested the possibility that the kernel might have marked the extension as untrusted, causing the system to intentionally block all network traffic as a safety mechanism. Has anyone experienced similar behavior with NEFilterDataProvider? Could there be a way to detect or prevent this state without rebooting? Is there any logging or diagnostic data I should collect when it happens again? Any guidance or pointers would be greatly appreciated. Thanks in advance!

I would like to know whether it is possible to collect Wi-Fi signal strength on iOS 18 from an iPhone app. I need to measure Wi-Fi signal strength for an internal app. The app is not intended for App Store distribution. I enabled the Access WiFi Information capability and tested NEHotspotNetwork.fetchCurrent(). SSID and BSSID are returned correctly, but signalStrength always returns 0.0. Is there any official or supported way to get the current Wi-Fi RSSI/signal strength on iOS 18? For example, is this possible through NEHotspotNetwork, NEHotspotHelper, or any other iOS API?

This issue has cropped up many times here on DevForums. Someone recently opened a DTS tech support incident about it, and I used that as an opportunity to post a definitive response here. If you have questions or comments about this, start a new thread and tag it with Network so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" iOS Network Signal Strength The iOS SDK has no general-purpose API that returns Wi-Fi or cellular signal strength in real time. Given that this has been the case for more than 10 years, it’s safe to assume that it’s not an accidental omission but a deliberate design choice. For information about the Wi-Fi APIs that are available on iOS, see TN3111 iOS Wi-Fi API overview. Network performance Most folks who ask about this are trying to use the signal strength to estimate network performance. This is a technique that I specifically recommend against. That’s because it produces both false positives and false negatives: The network signal might be weak and yet your app has excellent connectivity. For example, an iOS device on stage at WWDC might have terrible WWAN and Wi-Fi signal but that doesn’t matter because it’s connected to the Ethernet. The network signal might be strong and yet your app has very poor connectivity. For example, if you’re on a train, Wi-Fi signal might be strong in each carriage but the overall connection to the Internet is poor because it’s provided by a single over-stretched WWAN. The only good way to determine whether connectivity is good is to run a network request and see how it performs. If you’re issuing a lot of requests, use the performance of those requests to build a running estimate of how well the network is doing. Indeed, Apple practices what we preach here: This is exactly how HTTP Live Streaming works. Remember that network performance can change from moment to moment. The user’s train might enter or leave a tunnel, the user might step into a lift, and so on. If you build code to estimate the network performance, make sure it reacts to such changes. Keeping all of the above in mind, iOS 26 beta has two new APIs related to this issue: Network framework now offers a linkQuality property. See this post for my take on how to use this effectively. The WirelessInsights framework can notify you of anticipated WWAN condition changes. But what about this code I found on the ’net? Over the years various folks have used various unsupported techniques to get around this limitation. If you find code on the ’net that, say, uses KVC to read undocumented properties, or grovels through system logs, or walks the view hierarchy of the status bar, don’t use it. Such techniques are unsupported and, assuming they haven’t broken yet, are likely to break in the future. But what about Hotspot Helper? Hotspot Helper does have an API to read Wi-Fi signal strength, namely, the signalStrength property. However, this is not a general-purpose API. Like the rest of Hotspot Helper, this is tied to the specific use case for which it was designed. This value only updates in real time for networks that your hotspot helper is managing, as indicated by the isChosenHelper property. But what about MetricKit? MetricKit is so cool. Amongst other things, it supports the MXCellularConditionMetric payload, which holds a summary of the cellular conditions while your app was running. However, this is not a real-time signal strength value. But what about Wi-Fi Aware? Wi-Fi Aware supports a signalStrength property, and a new forcecast property in iOS 27 beta, but those only work in the context of Wi-Fi Aware; they do not represent a general-purpose API. But what if I’m working for a carrier? This post is about APIs in the iOS SDK. If you’re working for a carrier, discuss your requirements with your carrier’s contact at Apple. Revision History 2026-06-18 Added a discussion of Wi-Fi Aware. 2025-07-02 Updated to cover new features in the iOS 16 beta. Made other minor editorial changes. 2022-12-01 First posted.

We're developing a custom Thunderbolt device and want to expose it to macOS as an ethernet interface, while owning the full network stack implementation up to and including IP, TCP and UDP — bypassing the macOS network stack for those layers. Is IOEthernetController the right DriverKit approach for this, and does it allow intercepting traffic before it reaches the macOS IP stack?

I previously attempted to apply for the hotspot-provider entitlement but was rejected. I no longer require this entitlement. I need to remove the hotspot-provider permission although the Network Extensions capability is checked. However, the generated provisioning profile still includes the hotspot-provider permission, which causes error 409 when I upload the IPA file. I only need the Network Extensions entitlement. Could you please advise how to remove hotspot-provider from the provisioning profile?

When entering the following command in macOS 27 beta: lvbojie@Mac ~ % netstat -I nan0 1 Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll nan0* 1500 <Link#25> 66:31:00:4c:3c:b5 0 0 41 0 0 nan0* 1500 fe80::6431: fe80:19::6431:ff: 0 - 41 - - liushicong@Mac ~ % netstat -I nan0 1 The nan0 network interface is displayed. Does this indicate that macOS will support Wi-Fi Aware in the near future?

Hello, I'm developing a gambling blocker app that uses NEFilterDataProvider. My app was approved on the App Store, but the core feature doesn't work for end users. I have the content-filter-provider entitlement. Issue 1 — saveToPreferences() fails in distribution builds In dev builds (Xcode direct install), NEFilterManager.saveToPreferences() works fine — iOS shows a permission dialog and the filter is registered. In distribution builds (TestFlight/App Store), it fails immediately: NEFilterErrorDomain code 5 — Operation not permitted Console log from nehelper: "Creating a content filter configuration is only allowed through profile in production version" Issue 2 — .mobileconfig profile requires MDM Following the Console hint, I tried a .mobileconfig profile with com.apple.webcontent-filter payload (ContentFilterUUID, FilterType: Plugin, PluginBundleID). On an unsupervised consumer iPhone (iOS 18.5), installation fails: Profile Installation Failed — MDM required Question: What is the correct mechanism to activate a NEFilterDataProvider on a consumer (non-MDM) iPhone in a distribution build? Is there a specific entitlement or approval process I'm missing? (DTS Case-ID: 20087732)

(Also submitted as FB23072541) iOS 27 beta 1 brings a brand new error which ends up resulting in a state of .serverSetupIncomplete: <NEPIRChecker: 0x7de6c79b60>: -[NEPIRChecker start:responseQueue:completionHandler:]_block_invoke - PIR status returned error <Error Domain=com.apple.CipherML Code=1100 "Unable to query status due to errors: Error details were logged and redacted." UserInfo={NSLocalizedDescription=Unable to query status due to errors: Error details were logged and redacted., NSUnderlyingError=0x7de712f4e0 {Error Domain=com.apple.CipherML Code=1800 "Error details were logged and redacted." UserInfo={NSLocalizedDescription=Error details were logged and redacted.}}}> <NEAgentURLFilterExtension: 0x7de6d24e60>: -[NEAgentURLFilterExtension startURLFilter]_block_invoke - Failed to startFilter <Error Domain=NEMembershipCheckerErrorDomain Code=3 "(null)"> What’s a NEMembershipChecker? Member of what? Digging deeper I found these: Failed to prefetch tokens for group 'site.kaylees.Wipr2': Error Domain=NSURLErrorDomain Code=-1009 "The Internet connection appears to be offline." UserInfo={_NSURLErrorNWPathKey=satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi, LQM: good, NSErrorFailingURLKey=https://pirissuer.kaylees.site/token-key-for-user-token, NSUnderlyingError=0x7517125a40 {Error Domain=NSPOSIXErrorDomain Code=50 "Network is down" UserInfo={NSDescription=Network is down}}, _NSURLErrorPrivacyProxyFailureKey=true, NSLocalizedDescription=The Internet connection appears to be offline.} queryStatus(for:options:) threw an error: Error Domain=NSURLErrorDomain Code=-1009 "The Internet connection appears to be offline." UserInfo={_NSURLErrorNWPathKey=satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi, LQM: good, NSErrorFailingURLKey=https://pirissuer.kaylees.site/token-key-for-user-token, NSUnderlyingError=0x7517125b00 {Error Domain=NSPOSIXErrorDomain Code=50 "Network is down" UserInfo={NSDescription=Network is down}}, _NSURLErrorPrivacyProxyFailureKey=true, NSLocalizedDescription=The Internet connection appears to be offline.} The connection and the URL mentioned are fine of course, but "Network is down” now? This new problem only affects the App Store version of my app – not present if I install from Xcode. Users report that oddly, having an active VPN on the device works around this bug.

I'm implementing a NETransparentProxyProvider and trying to preserve the original TCP connection semantics as transparently as possible. The current API of NEAppProxyTCPFlow appears not to provide a way to distinguish between the following situations: The client has performed a half-close by calling shutdown(SHUT_WR) (i.e. closed only its write side). The client has fully closed the socket/connection. When readData(completionHandler:) returns empty data, indicating EOF, I cannot determine which of the two cases above has occurred. This creates a problem when forwarding the connection to the upstream server. Upon receiving empty data from the flow, should the corresponding server-side connection: Perform a half-close (close only the write side / send FIN)? Be fully closed? Currently, I always perform a half-close on the server-side connection. While this almost preserves the original flow semantics, it can lead to leaked connections, since the upstream connection may remain in FIN_WAIT_2 indefinitely. Is there any supported way to determine whether the originating connection was half-closed or fully closed? If not, what is the recommended approach for implementing a transparent TCP proxy that needs to accurately preserve TCP shutdown semantics? Any guidance would be appreciated.

We are developing a network extension that utilises the NEPacketTunnelProvider. We have noticed when the extension is running, and the phone screen is off, after about 10 seconds the device goes to system sleep (as evidenced by messages like “suspended timer for imminent system sleep” in the console logs) and the network extension simply won’t run any code during this time, therefore stopping traffic flow. When the device wakes up from sleep, such as when the screen comes on the network extension resumes executing code and runs normally. The use case is relaying traffic from a device on the same Wi-Fi network to our server via the iPhone's cell socket. As such, we need it to work reliably when the screen is off and not freeze the network extension. Is there any way to prevent the device from sleeping and freezing our extension when the screen is off? Also, if sleep causes the extension to pause code execution, then how would system services like APNS or includeAllNetworks (which forces all traffic through the tunnel) even work?